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SOME PUBLISHERS DROPPING PROTECTION 


During the past few months we have 
seen an interesting trend starting to de- 
velop among software publishers. Many 
of them, under increasing pressure from 
corporate users, are starting to drop 
software copy protection from their 
products. The latest publisher to join the 
pack is Software Publishing Corp., 
which produces the PFS line of 
programs. 

According to Software Publishing, 
they’ve finally realized that copy protec- 
tion is a big inconvenience for the cus- 
tomer and they don’t have to worry 
about protecting themselves so much 
any more because their business cus- 
tomers are protecting them and prevent- 
ing employees from making copies. 

I’m glad to see a movement away 
from copy protection. In fact, I think 
the whole issue of how much money is 
lost due to the production of illegal co- 
pies has been blown way out of propor- 
tion. There really hasn’t been any hard 
research to determine just how much 
money is lost due to piracy. There also 
hasn’t been any research done to deter- 
mine how much money is lost due to the 
problems and inconvenience caused by 
copy protection, and I think that would 
be a real eye-opener. 

Be that as it may, don’t run out to buy 
PFS software yet. According to a Soft- 
ware Publishing spokesman, the protec- 
tion is not going to be removed from 
existing products, but rather as new ver- 
sions of the various programs become 
available. 

In spite of the reasons given by Soft- 
ware Publishing for this move I tend to 
think the facts are a little different. I sus- 
pect that enough people have gotten fed 
up with copy protected software that 


they’ve just decided not to buy any. This 
is where we, the people who keep these 
companies afloat, can really show our 
strength. There is plenty of good soft- 
ware available that is not copy pro- 
tected. . 


Support unprotected shareware 


Much cf the unprotected software 
that is available is being put out on a 
“shareware” basis. What this means is 
the developer makes the diskette avail- 
able to anyone who wants it for a nomi- 
nal fee, ususally between $10 and $20. 
He tells the purchaser that he is free to 
make copies of the diskette and distrib- 
ute it to anyone he choses provided he 
doesn’t charge more than the developer 
does, doesn’t modify the diskette in any 
way and if he’s purchased documenta- 
tion separately he must agree not to 
duplicate it and give it away or sell it. 

These shareware programs generally 
come with a sufficient amount of 
documentation on the diskette so that 
the user can learn to run the program. 
The shareware developer’s hope is that 
the user will like the program so much, 
he’ll support the developer by paying an 
additional fee to register his copy, get 
more complete printed documentation 
and usually one or two future updates ° 
for free. Sometimes even the source 
code is made available. 

If you think these developers are fool-_ 
ish for taking this approach, think 
again. Several shareware developers 
have made over $1 million so far and 
their programs are as good as, or better 
than many commercial products costing 
hundreds of dollars more. 
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Cracks Wanted 


Listed below are programs that our 
readers would like to unprotect. Anyone 
who comes up with a method of remov- 
ing the protection from any of these pro- 
grams will get a free three-month 
subscription, or extension to ASPD, so 
get those solutions in. 

If you have a program that you’d like 
to see unprotected, please let us know, 
and we'll add it to our list so that some 
of our readers can try their hands at it. 


1. Sensible Speller — DOS Version 
2. Sensible Speller — ProDOS Version 
3. Crush, Crumple & Chomp 

4. Wizardry 

5. Educational Software from Compress 
6. Dazzle Draw 

7. Newsroom 

8. Word Handler 

9. Disk-O-Check 


Crack Index 


In order to make life just a little more 
convenient for you, each issue of Apple 
Software Protection Digest will contain 
a list of all of the programs cracked so 
far and what issues these cracks ap- 
peared in. This will save you from go- 
ing through all past issues of the digest 
in order to find a particular crack you 
are looking for a crack to a particular 
program. 


Bookends — Vol. 1, No. 1, p. 7 
Homeword — Vol. 1, No. 2, p. 9 
Homeword Speller — Vol. 1, No. 2, p. 9 
PFS Series — Vol. 1, No. 2, p. 7 
Print Shop — Vol. 1, No. 1, p. 10 
Print Shop Companion — Vol. 1, No. 
2, p. 6 

Sensible Grammar — Vol. 1, No. 2, p.7 
Time Is Money — Vol. 1, No. 2, p. 9 


Don’t miss a 
single issue 


SUBSCRIBE 
TODAY! 


Letters 


Dear Editor: 


I liked your courtesy copy of ASPD 
and I’m going to try it for a year. I’m 
also ordering your diskette. I do have a 
problem however. 

Iam a writer and like Applewriter ]/, 
but it has two limitations which center 
around its copy protection. Oh, it’s easy 
enough to make a backup copy of it (I 
use Locksmith 4.1). The nature of its 
copy protection however, makes it-im- 
possible to either put it onto a hard disk, 
or use it with one. I can’t get the com- 
puter to recognize the slot after I’ve 
booted AW J[. 

My problem can be solved in one of 
two ways, as I see it. I need a way to 
modify a copy program, like Locksmith 
4.1 or a way to copy Apple Writer ][ that 
leaves it unprotected. Then I could put 
it onto my hard disk easily. Can you tell 
me how to do this? 

I know this much, after my ex- 
periences over the last few months, I 
won’t buy a copy-protected program 
again. They are just too inconvenient to 
use. 


Lee Baldwin 
Concord, CA 


The quick answer to your first question 
is yes, we can help you. This issue con- 
tains a full-length article devoted to un- 
protecting Apple Writer. If you don’t 
want to read the whole thing, but just 
want the parameters for the COPYP 
program, they can be found in the 
COPYP Parameter List. The reason 
Applewriter doesn’t recognize your hard 
disk is that the modified DOS that is 
needed to recognize your hard disk is 
replaced by the protected DOS of Ap- 
ple Writer. If your hard disk is a Sider 
and you have a way of breaking out of 
the program into the monitor mode, you 
may be able to patch DOS so that it can 
use your hard drive. The patching infor- 
mation can be found in the Sider User’s 
Guide on page 133. 


Dear Editor: 


I just read about your Apple Software 
Protection Digest. If it is as excellent as 
it has been reported to be, I will gladly 
pay the annual subscription fee. Please 


, send me a sample issue. 


By the way, I bought a game called ; 
Crush, Crumble and Chomp and n@® 
ven’t been able to make a backup copy. 

If you know of any way of doing so, 
please give me full details. 


Michael Jacobs 
Wolcothville, IN 


Here’s your sample copy Mike. I hope 
we’ve lived up to our advance billing. E 
I’m adding your request to our Cracks 
Wanted list. If any of our readers can 

tell Mike how to back up Crush, Crum- : 
ble and Chomp, let’s here from you. 


Dear Editor: 


I was happy to see that my programs 
(Two Solutions to the Hide-A-Line 
Problem) had won your contest and 
were published in ASPD #2. I must con- 
fess though, that I have encountered a 
problem with the concept of hiding a 
line by resetting the link bytes. 

The problem stems from the fact that 
any line hidden in this manner will cause 
an UNDEF’D STATEMENT error if 
the program does a GOTO or GOSUB 
to it. Has anyone else run into this@®. 
dilemma? 

Because of this apparent glitch, I 

much prefer the method of adding five 
colons at the start of the program line. 
The GOTO/GOSUB problem does not 
occur when using this technique. I’ve 
had lots of fun using this technique and 
baffling “unaware” people with it. 

Thanks for the extra six months, I 
look forward to future issues of ASPD. 

You present ideas and concepts that 4 
many of us can experiment with and 
learn from, something that is missing 
from many Apple periodicals nowadays. f 


Mark Landwehr f 


Thanks for your letter Mark. The 
problem you encountered with the GO- 
TOs and GOSUBs in the first line hid- 
ing technique is to be expected. When 
Applesoft encounters a GOTO or 
GOSUB, the 6502 starts scanning the 
BASIC program from the beginning (via 
the next line pointers) and looks at the : 
two bytes that follow each next line ? 
pointer to see if the line that is desired 
has been found. Since we’ve changed i 
these pointers so that they bypass the 4 
line when the program is listed, the line 
will also be bypassed when GOTOs and 
GOSUBs are encountered. 
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HOW TO CRACK A PROGRAM 


Many people have written to me and 
told me that they appreciate being given 
step-by-step instructions on how to 
backup or crack a particular program. 
They also indicated however, that they 
would like to know how one goes about 
starting to crack a program and develop 
their own technique for backing it up. 
That’s really a tough question to answer 
because there are almost an unlimited 
number of ways to go about cracking a 
program. To get you started however, 
I'll take you step-by-step through the 
thought processes involved in cracking 
Applewriter //e (DOS version). The rea- 
son this program was chosen was be- 
cause one of our readers sent in a letter 
asking how he could remove the protec- 
tion from Applewriter so that he could 
use it with his hard disk. 

If you’re not interested in knowing 
how Applewriter //e is unprotected, but 
just interested in unprotecting it, you 
can skip the rest of this article and sim- 
ple use the COPYP parameter file that 
is listed elsewhere in this issue to auto- 
matically make an unprotected back up. 


Know it well before you start 


Before you attempt to crack any pro- 
gram, it is essential that you use it and 
become thoroughly familiar with it. If 
you know how the program will act in 
various situations, you will have an 
enormous advantage working for you 
when you try to figure out how the pro- 
gram is protected. 

If you had become familiar with Ap- 
plewriter //e before you attempted to 
crack it, you would have discovered that 
the Applewriter disk uses a fairly nor- 
mal form of DOS. In fact, the diskette 
can be CATALOGed like a normal 
DOS diskette and you can use COPYA 
to make a copy of the diskette. While 
no error is generated when the copy is 
made, don’t rejoice too quickly, because 
the copy will not work. Nevertheless, 
since the modification to standard DOS 
seems to be small, chances are pretty 
good that it won’t be too difficult to 
crack the protection. This is generally 
true for most protected programs. The 
closer they are to standard DOS, the eas- 
ier they are to crack. 

Since we know that DOS 3.3 is more 
or less intact, we can find out what the 
boot program is. It’s important to un- 
derstand how a program boots up in 
order to crack its protection. By using 


a sector editor, such as the one availa- 
ble on the Copy ][ Plus diskette, we can 
look at track $1, sector $9, byte $75 
(remember the $ indicates the number 
is a hexadecimal number), which is 
where we’ll find the name of the pro- 
gram that is automatically run when the 
diskette is booted. In the case of Ap- 
plewriter //e, the file is called 
OBJ.BOOT. It is‘a binary file and it is 
automatically BRUN when the diskette 
is booted. 

The job of OBJ.BOOT is simple. It 
tests to see if the computer that is being 
used is a Apple //e. If it’s a // Plus, it 
will run the program OBJ.APWRT][D 
which simply prints a message to the 
user telling him that an Apple //e is re- 
quired to run the program. If the com- 
puter being used is a //e, OBJ.BOOT 
then checks to see how much memory 
is available. If only 64K is available, 
then the file OBJ. APWRT][E is run. On 
the otherhand, if 128K or more of RAM 
is available, OBJ.APWRT][F will be 
Tun. 


Prepare all your tools 


. Before you attempt to crack a pro- 
gram, it is essential that you have some 
basic tools. To begin with, you need a 
sector editor that will let you read, 
modify and write diskette sectors. The 
second thing you’ll need is a diskette 
searching pfogram. This is a program 
that will let you enter a string of charac- 
ters or hex values to be searched for on 
a diskette. Both of these capabilities are 
available in the Copy ][ Plus program 
(which normally retails for $39.95 but 
costs only $30 when you buy it through 
us). Next, you should have a short, in- 
memory search program that can be 
used to locate a sequence of bytes in 
RAM. For our Applewriter //e crack, 
we'll use a short machine language 
search routine that Bob Sander-Cederlof 
gives away with his S-C Macro Assem- 
bler. It’s only 53 bytes long and can eas- 
ily be keyed in when needed. The last 
thing you’re going to need is a way of 
breaking out of the program once it’s 
running. I have found that the Wildcard 
2 board is excellent for this purpose. It 
allows you to press a button at any time 
and then gives you a menu that let’s you 
do several things, including jumping to 
the monitor. It plugs into any slot in the 
computer and will work on any Apple 
or compatible except the Apple //c 


(which has no slots). 


STEP 1: Copy it if you can 


When trying to crack a protected pro- 
gram, always try to copy it first with 
COPYA. If you can’t get anywhere at 
all, another approach will have to be 
taken. But if you can copy it, as is the 
case with Applewriter //e, you’ve gone 
a long way towards your ultimate goal. 
Once you’ve made a copy of the dis- 
kette, try to boot it up. Pay close atten- 
tion to what happens during the boot 
process and compare it to what happens 
during a normal boot of the original 
diskette. 

In the case of Applewriter //e, when 
the copy is booted, OBJ.BOOT is run 
and if an Apple //e is being used, de- 
pending on how much RAM is availa- 
ble, either OBJ.APWRT][E or 
OBJ.APWRT][F is run after it. 
Whichever file is activated, if the dis- 
kette is a copy, the program will detect 
this, zero out all of memory and then 
jump to Applesoft BASIC, most likely 
via the - ‘cold start’ entry point at 
$E000. It is this jump to BASIC that 
turns out to be the Achilles Heel of Ap- 
plewriter //e. 


STEP 2: Boot the program 


After you’ve made a backup copy of 
Applewriter //e, put it aside and boot 
the original diskette. Once the program 
is loaded and you get to the opening ti- 
tle screen, get into the monitor. I do this 
by pressing the button on my Wildcard 
2 and selecting the jump to monitor op- 
tion from the menu that is presented. 

Once you're in the monitor, the whole 
world of Applewriter is open to you. 
You can examine the program code to 
your heart’s content, but you won’t be 
able to modify it and save it out to the 
diskette because you don’t have access 
to anormal DOS. Nevertheless, there’s 
a lot you can do to unprotect the pro- 
gram from this mode. 


STEP 3: Search the program 


Once you're in the monitor, you can 
search for Applewriter’s Achilles Heel, 
the jump to BASIC which occurs when 
the program determines that an original 
diskette is not being used. You can of 
course search the computer’s memory 
manually and examine every location 
yourself. A much easier way to do it 
however, is to let the computer do the 
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hard work. If you examine page 3 of 
memory (addresses starting at $300) 
you'll find that most of it has been 
zeroed out. Thus, it is a handy spot for 
us to put in a short machine language 
program that will do the searching for 
us. 

Since we don’t have access to the disk 
drives from the monitor mode, we can’t 
load the program in from the disk. The 
only other choice is to load it in from 
tape, for those people who still have this 
capability in their computers (I think it 
was eliminated with the enhanced Ap- 
ple //e ROMs) or key it in directly. 
Since the program I use is short (only 
53 bytes long) I key it in whenever I need 
it. Eventually, I'll probably put it in an 
EPROM that can be switched in 
whenever the program is needed, but 
that’s another project. 

As I mentioned earlier, this search 
program is one of several sample pro- 
grams that come on the S-C Macro As- 
sembler diskette from S-C Software. 
The program itself is easy to use and it 
allows you to specify the starting and 
ending locations of the range to be 
searched, the byte sequence to be 
searched for and it allows you to desig- 
nate any particular character as a wild- 
card character. You can examine the full 
assembly language source code listing to 
see how it operates, or simply key in the 
seven lines listed below. 


300:A9 03 8D FA 03 AS 10 8D 
308:F9 O03 A9 4C 8D F8 O03 60 
310:A2 00 AO OO BS 02 C5 O1 
318:FO 04 D1 3C DO 11 C8 EB 
320:E4 00 DO FO AS 3C 85 3A 
328:A5 3D 85 3B 20 DO F8 20 
330:BA FC 90 DC 60 


Once the search program has been keyed 
in, it must be initialized by typing 300G 
from the monitor mode. Now you’re 
ready to do your searching. Since we 
know that the jump to BASIC is as- 
sociated with the protection scheme, if 
we find that, we can probably work our 
way back towards the beginning of the 
protection scheme code. Thus, it’s im- 
portant for us to locate this jump to 
BASIC. The machine code required to 
jump to BASIC should contain a three- 
byte sequence that looks like this: 


4C 00 EO 


so we'll search through memory for this 
sequence of bytes. We do this by plac- 
ing a 3 in memory location 0 on the zero 
page of memory to indicate how many 


bytes are in the sequenceof characters 
we’re looking for. Next, we place the 
value of the wildcard character in loca- 
tion 1. Since we have no need of a wild- 
card character in this particular search, 


I just place an FF in this location. Fi- - 


nally, we have to enter the sequence of 
bytes that are being searched for start- 
ing with location 2 on zero page. In sum- 
mary, the following line must be entered 
(from the monitor mode) to set up the 
search parameters: 


0:03 FF 4C 00 E0 


All that’s left to do now is specify the 
range of memory locations to be 
searched and activate the program. Both 
of these tasks are done together by typ- 
ing in the starting and ending address- 
es, separated by a period, entering a 
Control-Y and then pressing the 
RETURN key. Since RAM ends at 
$BFFF I decided to search all of 
memory from $800 to $BFFF. To do 
this the following line was entered while 
in the monitor mode: 


800.BFFF <Control-Y > 


Notice that I’ve placed spaces after the 
BFFF and the Control-Y. This is for 
ease of reading only and these spaces 
should not be used when you enter this 
line. 


STEP 4: Find where it begins 


When you search memory for this 
string of characters, you see that it ap- 
pears only once, at location $2D0C. 
This is indicated by the search program 
which prints out the following line in 
response to your search: 


2D0C- 4C 00 EO JMP $E000 


Since that’s the only place in the pro- 
gram where the jump to BASIC occurs, 
chances are pretty good that starting at 
this location and working our way back- 
wards, we should be able to find the pro- 
tection code. As you work your way 
back, look for another JMP instruction 
or an RTS instruction. The first one you 
encounter on your journey back in 
memory will usually mark the end of 
some previous routine and the beginning 
of the routine your examining. In the 
case of Applewriter //e, 1 encountered 
a JMP $0200 at $2CDD. At the time I 
didn’t pay much attention to it, although 
I should have because it is very unusual 


to jump to a subroutine that is located 
in the input buffer, unless of course’ 
you’re trying to hide something. My 
failure to pay attention to this caused 
one false start, but that was quickly cor- 
rected. I’ll get back to that in a little 
while. 

Since the JMP instruction takes up 
three bytes, that means that the subrou- 
tine I was examining probably started at 
$2CDO0. The listing of the code that re- 
sides between $2CDO and $2DOC, where 
control is passed to BASIC is shown be- 
low. This listing was made by using the 
Apple’s built-in disassembler and I have 
added line numbers to this listing so that 
it will be easy to reference a particular 
line. 


100 2CDO- AD 83 CO LDA $C083 
110 2CD3- AD 83 CO LDA $C083 
120 2CD6- AI O03 LDA #$03 
130 2CD8- 85 O1 STA $01 
140 2CDA- AO 00 LDY #$00 
150 2CDC- 84 00 STY $00 
160 2CDE- 98 TYA 

170 2CDF- 91 00 STA ($00),Y 
180 2CE1- C8 INY 

190 2CE2- DO FB BNE $2CDF 
200 2CE4- E6 01 INC $01 
210 2CE6- FO OC BEQ $2CF4 
220 2CE8- A6 O1 LDX $01 
230 2CEA- EO CO CPX #$CO 
240 2CEC- DO F1 BNE $2CDF 
250 2CEE- A2 DO LDX #$DO 
260 2CFO- 86 01 STX $01 
270 2CF2- DO EB BNE $2CDF 
280 2CF4- AD 82 CO LDA $CcO82 
290 2CF7- AD 82 CO LDA $CO082 
300 2CFA- 8D OC CO STA $cooc 
310 2CFD- 20 84 FE JSR $FE84 
320 2D00- 20 2F FB JSR $FB20 
330 2D03- 20 93 FE JSR $FE93 
340 2D06- 20 89 FE JSR $FE89 
350 2D09- 20 58 FC JSR $FC58 
360 2D0C- 4C 00 EO JMP $E000 


STEP 5: Examine the code 


Now that we know where at least 
some of the protection code lives, let’s 
take a close look at it to see what it does. 
Because Applewriter //e wipes out all 
of memory before jumping to BASIC 
when a copied diskette is encountered, 
we would expect this routine to perform 
that task, and it does. Here is a detailed 
explanation of exactly what goes on 
when this routine is called. 

In lines 100 and 110, the RAM card 
in the computer is write enabled, so that 
data can be stored in it. Lines 120 to 150 
set up a pointer on page zero that will 
be used to indicate which memory loca- 
tions are to be zeroed out. Here the pro- 
gram starts with location $300. Line 160 
loads a zero into the accumulator and 
line 170 is the line that actually zeroes 
out the current memory location that is 
being pointed to. The Y-register was in- 
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itially zero and is incremented in line 
180. This allows the instruction in line 
170 to point to every location on a par- 
ticular page of memory. As long as the 
Y-register has not returned to zero (been 
incremented 256 times) the program 
loops back to line 170 and keeps stor- 
ing zeroes in successive memory lo- 
cations. : 

Once the Y-register does become zero 
again, line 200 increments the page 
pointer so that the next page of memory 
is set up to be zeroed out. As long as lo- 
cation $01 does not contain a zero (and 
it won’t until the very last byte of avail- 
able memory has been addressed) con- 
trol passes from line 200 to line 220 
where the contents of location $01 are 
loaded into the X-register. Line 230 
checks this value to see if it is equal to 
$CO. If it isn’t, control is passed once 
again to line 170. In this manner, all of 
memory from $300 to $BFFF (which is 
one less than $C000 which was just 
checked for) is zeroed out. 

Because Applewriter //e also uses the 
RAM card, the program then goes on 
to wipe out all memory locations there 
as well, which is why the RAM card was 
write-enabled earlier. The RAM card’s 
memory starts at $D000 and so line 250 
loads a $D0 into the page counter at lo- 
cation $01 on page zero. Control is once 
again passed to line 170 and the program 
loops once more to zero out all succes- 
sive memory locations. This time 
however, after a zero is stored in loca- 
tion $FFFF on the RAM card, the page 
counter is incremented again and thus 
returns to zero. This triggers the instruc- 
tion in line 210, which causes the com- 
puter to jump to line 280 where the 
RAM card is turned off. 

Since Applewriter //e uses the 80 
column mode when it is active, the next 
instruction (line 300) turns off the 80 
column card and activates the 40 column 
mode. Line 310 makes sure the Apple 
is set up for normal (not inverse or flash- 
ing) video while line 320 makes sure the 
text screen and not either of the graph- 
ic screens, is activated. Line 330 does a 
PR#O0 to make sure the output hooks at 
$36 and $37 are returned to their nor- 
mal condition. Similarly, line 340 does 
and IN#O0 to restore the input hooks ($38 
and $39). Finally, line 350 clears the 
screen and line 360 jumps to BASIC, 


STEP 6: Find it on the disk 


Now that we’ve located the protection 
routine and understand how it operates, 


we have to find out where its located on 
the diskette, so that it can be modified. 
To do this, we’re going to have to use 
a disk scanning program which, like the 
short machine language program we en- 
tered earlier, will let us search for a par- 
ticular byte sequence. Several such 
programs are available commercially. I 
use the one that is on the Copy J[ Plus 
diskette. You get to it by selecting the 
Sector Editor option and then pressing 
the S key. The program will then ask 
you if you want to enter your search 
string as hex codes or text. Typing an 
H selects the hex code mode. 

Since we know from the disassembly 
listing that starts at $2CDO what we’re 
looking for the job is not to difficult. 
I decided to search for the first eight 
bytes of the routine that starts at $2CD0O 
— AD 83 CO AD 83 CO A9 03. It seemed 
to me that this sequence of bytes would 
be fairly unique, and would probably 
only be encountered in the protection 
code. After entering this data, I found 
that the code was stored on track 3, sec- 
tor 9 and started at byte 1 (which is the 
second byte in the sector because we 
start with 0). I continued searching the 
diskette to see if the code would crop up 
somewhere else, and sure enough it did, 
at track 6, sector B, byte D4. The fact 
that the code was found in two places 
on the diskette suggested that the code 
was located in the OBJ.APWRT][E and 
OBJ.APWRT][F files. 


STEP 7: Disable the protection 


Once you find where the offending 
code is located on the diskette, all you 
have to do is disable the protection. In 
this case, that can easily be done by stor- 
ing a $60 (the RTS code) at the very be- 
ginning of the protection scheme code. 
To do this you'll need a sector editor 
that will let you read, modify and then 
write a diskette sector. Always remem- 
ber, NEVER WRITE ON THE ORIGI- 
NAL. Do all of your work on a copy 
only, Once again, I have found that 
Copy J{ Plus is the tool to handle the 
job. Using the copy that I made, but 
wouldn’t boot, I stored a $60 at track 
3, sector 9, byte 1 and track 6, sector B, 
byte D4. 


STEP 8: Test it out 


With patches applied to the non- 
working copy, it is now time to test it 
out. Booting up this diskette, I was 
delighted to see that the boot proceed- 


ed as normal and was rewarded with the 
normal Applewriter opening screen. But 
my joy was to be short-lived. After go- 
ing through a short sample session, I at- 
tempted to quit Applewriter and lo and 
behold, I couldn’t get out of it. It seems, 
that as part of the procedure for quit- 
ting the program, the memory wipeout 
routine that I just disabled, gets called 
into action. Back to the drawing board. 


STEP 9: Find why it failed 


With a lot of luck, you'll be able to 
skip this step. but such was not to be the 
case with Applewriter. At this point, I 
remembered the strange JMP $0200 in- 
struction that I saw immediately before 
the memory wipeout routine and 
proceeded to examine it and the code be- 
fore it more carefully. I discovered that 
immediately preceding the protection 
routine was another routine that trans- 
ferred the original wipeout code into the 
input buffer where it was then executed 
by the JMP $0200 instruction. The short 
routine that does the moving starts at 
$2CBF. This apparently was the real 
protection routine. 

Once again, I typed in the memory 

search program and looked for the place 
where this code was called from using 
the byte sequence: 4C BF 2C. It turns 
out that this sequence of bytes is locat- 
ed at $3B04 (when OBJ.APWRT][F is 
loaded). Examining the code that pre- 
cedes this JMP instruction reveals the 
routine that is used to check and see if 
the disk that is in the drive is an origi- 
nal. This code starts at $3AF1 when 
OBJ.APWRTI[F is loaded and is listed 
below. 
Without going into a lot of detail, this 
routine calls another one that immedi- 
ately follows it (at $3B08) and reads the 
disk. This routine checks for the correct 
prologue bytes in the address field of the 
sectors (for more information see Pro- 
tection Tutorial - Part II, ASPD Vol. 1, 
No. 2, p. 20). It then checks for special 
information that is only present on the 
original Applewriter //e diskette. If it 
doesn’t find that information, it jumps 
to the memory wipeout routine at 
$2CBF. 

By the way, it’s important to note that 
any protection scheme that accesses spe- 
cial information on a diskette, be it spe- 
cial sync bytes, extra data or a nibble 
counting routine, must access the dis- 
kette with an instruction such as LDA 
$CO8C,X where X contains the slot 
number that the disk drive is connected 


6 

_ 3AF1- 20 08 3B JSR $3B08 
SAF4— 85 82 STA $82 
3AF6- 20 08 3B JSR  $3B08 
SAF9- C5 82 CMP $82 
3AFB— DO OA BNE $3B07 
3AFD- 20 08 3B JSR $3B08 
3BOO0- C5 82 CMP $82 
3B02- DO 03 BNE $3B07 
3B04- 4C BF 2C JMP $2CBF 
3BO7- 60. RTS 


3BO8- AE E1 02 LDX 
3BOB- BD 8C CO LDA $COBC,X 


3BOE- 10 FB BPL $3BOB 
3B10- C9 DS CMP #$D5 
3B12- DO F4 BNE $3B08 
3B14- EA NOP 

3B15- BD 8C CO LDA $CO8C,X 
3B18- 10 FB BPL $3B15 
3B1A- C9 AA CMP #$AA 
3B1C- DO F2 BNE, $3B10 
SB1IE- EA NOP 

3B1F- BD 8C CO LDA $cOosc,x 
3B22- 10 FB BPL $3B1F 
3B24- C9 96 CMP) #$96 
3B26- DO E8 BNE $3810 
3B28- EA NOP 

3B29- EA NOP 

3B2A- BD 8C CO LDA $cosc,x 
3B2D- 10 FB BPL $3B2A 
3B2F- 2A ROL 

3B30- 85 80 STA $80 
3B32- BD 8C CO LDA $CO08C,x 
3B35- 10 FB BPL $3B32 
3B37- 25 80 AND $80 
3B39- 60 RTS 


to. Searching a diskette for the bytes 
that represent this instruction — BD 8C 
CO — will usually get you to the protec- 
tion code, eventually. The problem is 
that any other routine that has a legiti- 
mate need to access the disk drive will 
also use similar code, so you’ll have to 
examine a lot of code before you get to 
what you want. Therefore, always try to 
get close to your protection routine by 


other means first, just as we did here. 

Now that we know what the true pro- 
tection scheme looks like, let’s use our 
disk scanner again and try and locate on 
the diskette. Remember, we’re working 
with the copy of the original that we 
made only! Using the search pattern C5 
82 DO 03 4C, I located three possible 
candidates. Finding three patterns dis- 
turbed me a bit because I had expected 
only two, as in the previous case. The 
three patterns were located on track 4, 
sector C, byte B1; track 7, sector C, byte 
8 and track 7, sector E, byte 1. Since I 
had one more bit pattern than I antici- 
pated I examined each carefully and 
found that while the last pattern start- 
ed out the same as the other two, it was 
significantly different after the first 
several bytes and most important, it did 
not have the disk access instructions. 
This routine was therefore discarded 
and only the first two were used. 

To eliminate the protection, once 
again the first byte of these two routines 
was replaced with a $60, the machine 
language code for the RTS instruction 
(ReTurn from Subroutine). Thus, a $60 
was placed on track 4, sector C, byte B1 
and track 7, sector C, byte 8. After test- 
ing the diskette this time, the program 
worked perfectly. The interesting thing 
about this whole thing is that all it took 
was a two byte change on the copy of 
the Applewriter //e diskette to make it 
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a working copy. The only reason it was 
necessary to change two bytes was be- 
cause there were two different versions 
of the program on the diskette. Other- 
wise, only a single byte change would 
have been necessary. Isn’t the power of 
information astounding? 

If you don’t have all of the tools that 
I used to crack this program, I suggest 
you get them right away, if you antici- 
pate cracking more software. In the 
meantime, if you just want to make an 
unprotected copy of Applewriter //e, 
you can use the COPYP program that 
appeared in the last issue and the Ap- 
plewriter //e parameters that are listed 
in the COPYP Parameters section of the 
digest. 

I’ve spent a lot of time explaining the 
step-by-step process that I went through 
to crack this program so that you could 
understand the thought process that 
went on. This will help you to crack 
other programs, but don’t expect any 
miracles. There are many different ways 
in which programs can be protected and 
this has only been one of them. Hope- 
fully, however, you’ve gained some in- 
sight that can be applied to other 
programs. If you do crack any other @ 
programs, let us know how you did it 
so that we can share the procedure with 
the rest of our readers. We'll reward you 
with an extension of your subscription. 
Let’s hear from you soon. 


PARAMETER FILES FOR COPYP 


Listed below are several parameter 
files for use with the COPYP program 
that was presented in ASPD Vol. 1, No. 
2. You can key these lines in directly or 
you can do what I do and create text 
files that contain these lines. Then you 
can load in COPYP and EXEC in the 
appropriate file for the program you 
want to copy. You can keep these text 
files on a diskette and re-use them again 
whenever you want to make another 
copy. 

Some of these files have been tested 
by me and some haven’t. It gets to be 
an expensive proposition to buy each of 
these programs in order to test out each 
file. Therefore, if you submit files to us, 
please make sure you test them 
thoroughly. Also, please give us the ver- 
sion number of the program you’re 
cracking. Nothing is more discouraging 


than trying to use a routine that is sup- 
posed to work, only to find out that it 
doesn’t. Your reward for doing this will 
be a one-month addition to your sub- 
scription. 


Applewriter //e 


A complete explanation of how Ap- 
plewriter //e is unprotected is included 
in a separate article in this issue. For 
those of you who are merely interested 
in making an unprotected copy of it and 
not interested in the how and the why, 
just add the following lines to your 
COPYP program and make as many 
unprotected copies as you want. 


1000 DATA 4,12,177,76,96 
1010 DATA 7,12,8,76,96 


Financial Cookbook 


Financial Cookbook from Electron- 
ic Arts is a program that can be easily 
unprotected by changing just a single 
byte in the program. The reader who 
supplied the information for unprotect- 
ing this program and the next couple of 
programs neglected to tell us what the 
value of the original byte that is being 
changed was. 

Since we have been unable to contact 
him so far, we decided to add a slight 
modification to COPYP that would 
enable you to unprotect a program 
without having to know what the origi- 
nal value of the byte that’s being 
changed is. This of course bypasses the 
built-in safeguard that doesn’t let you 
modify a different version of the pro-@ 
gram (which is determined by checking 
to see that the original value of the byte 
is what it should be) but it can come in 
handy sometimes. 

continued on page 11 
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ADD UNDELETABLE LINES TO YOUR PROGRAM 


For those of you who write programs 
in Applesoft BASIC this next program 
will be of some interest to you. Did you 
ever see some commercial programs that 
had a copyright notice and author credit 
listed at the bottom of the program us- 
ing line numbers that somehow could 
not be deleted? Have you ever wondered 
how you could do the same thing? It’s 
easy and this program will help you to 
do it. 

Most Applesoft BASIC programmers 
eventually discover that the highest line 
number that can be entered in an Ap- 
plesoft program, from the keyboard, is 
63999. That next to the last phrase 
”...from the keyboard...” is the key here 
however. The designers of Applesoft, 
for some reason, decided to make it ille- 
gal to have line numbers that were great- 
er than 63999. Therefore, everytime that 
a line is entered from the keyboard, the 
computer checks to see if the line num- 
ber is greater than 63999. If it is, the 
computer gives you a SYNTAX ER- 
ROR message. Since the checking is 
done as the line is entered, if we can find 
someway to bypass the input routine, we 
can have larger line numbers in our pro- 
gram and everything will work fine. As 
an added bonus, once we have this larg- 
er numbered line in our program, there 
will be no convenient way to delete it. 

To make life easy, what I generally do 
is write out the lines that are to become 
permanent additions to my program as 
a separate file and then I run this short 
program, while that file is in memory. 
I then save the resulting program, which 
is usually just REMs with my name and 
a copyright notice in them, out to disk. 
When I finish developing an Applesoft 
program, I then merge the newly deve- 
loped program with my short credit file 
program and I now have a program that 
contains the proper credit to me in lines 
that are difficult (but not impossible) to 
delete. 

This program, A/l Line Numbers to 
65535 does just what its name implies, 
it changes all line numbers in any par- 
ticular program to 65535. For those of 
you who may be wondering just how its 
possible to have a program with more 
than one identical line number, I'll ex- 
plain in a minute. Suffice it to say that 
you can’t have it if the lines are being 
entered from the keyboard, because the 
moment you enter a second line with a 
number that is identical to an already ex- 
isting line, the old line with the same 


0317- 
0319- 
031B- 
031D- 
03 1F- 
0322- 
0324- 
0325- 
0326- 
0329- 
032B- 
032D- 
O32F- 
0330- 
0331- 
0333- 
0334- 
0336- 


0338- 
O33A- 
033C- 
O33E- 
0340- 
0342- 
0346- 
0346- 
0348- 


0349- 
034C- 
O34F- 
0362- 
0356- 
0368- 
O036B- 
O36E- 
0361- 
0362- 
0364- 


03 


03 


03 


FD 


cc 
ce 
AO 
co 
02 
D4 
B6 
B3 


Ao 


1000 
1010 
1020 
1030 
1040 
1060 
1060 
1070 
1080 
1090 
1100 
1110 
1120 
1130 
1140 
1160 
1160 
1170 
1180 
1190 
1200 
1210 
1220 
1230 
1240 
1250 
1260 
1270 
1280 
1290 
1300 
1310 
1320 
1330 
1340 
1350 
1360 
1370 
1380 
1390 
1400 
1410 
1420 
1430 
1440 
1450 
1460 
1470 
1480 
1490 
1500 
1510 
1520 
1630 
1640 
1650 
1660 
1670 
1580 
1690 
1600 
1610 
1620 
1630 
1640 
1650 
1660 
1670 
1680 
1690 
1700 
1710 
1720 
1730 
1740 


1760 
1760 


Peerer errr iii titi ir 
ane ane 


ALL LINE NUMBERS TO 66535 **#*#* 
aoe 
Copyright (C) 1986 by 
Jules H, Glider 
All Rights Reserved eae 
Prey wen 
PrIeIriririi iti iii iit 
. 
* 
* Equates 
* 
TXTPTR -EQ $06 
POINTER -EQ $08 
TXTTAB -EQ $67 
PRGEND -EQ SAF 
HOME -EQ $FC58 
COUT -EQ $FDED 
* 
-OR $300 
* 
JSR HOME Clear the screen. 
LDA #TEXT Point to the text 
LDY /TEXT that Is to be printed. 
JSR MSGPRT Print it. 
LDA TXTTAB Get the start of 
LDY TXTTAB+1 program pointer 
ENDCHK CMP PRGEND Compare with the 
BCC NEXT end of program 
CPY PRGEND+1 pointer to see if 
BCC NEXT we're done yet. 
RTS Yes, we’re.done. 
. 
* This section of the program saves the 
* pointer to the current line and then 
* replaces the IIne number In that Jine 
* with the number stored in LINNBR, in 
* this case #$FFFF which Is 65535. Next, 
* the pointer is updated to point to the 
* next -ine. The program then jumps to 
* a routine that checks to see if we've 
* reached the end of the program. 
* 
NEXT STA POINTER Save the line 
STY POINTER+1 pointer. 
LDX #$0 Inittalize the 
LDY #$2 offset counters. 


LDA LINNBR,X Get the low byte 
STA (POINTER) ,Y of the new number 
INX and replace the 
INY old one. 
LDA LINNBR,X Get the new high 
STA (POINTER) ,Y and replace old. 
LDY #$0 
LDA (POINTER) ,Y Update POINTER to 
PHA point to the next 
INY line. 
LDA (POINTER) ,Y 
TAY 
PLA 
JMP ENDCHK 
* 
* This Is the message printing routine. 
* 
MSGPRT STA TXTPTR Store the pointer 
STY TXTPTR+1 to the message. 
LDY #$0 Initlallze offset. 
Loop LDA (TXTPTR),Y Get next character. 
BEQ ENDPRT Done yet? 
JSR COUT No, print It. 
INY Point to next character, 
BNE LOOP Go get It. 
ENDPRT RTS Return to caller. 
. 


TEXT AS ="ALL LINE NUMBERS TO 66636" 
.HS 8D8D 
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number gets erased and is replaced by 
the new one. 

Multiple lines with the same number 
are possible however. To accomplish 
this bit of micro magic, we must first 
type in lines with ordinary line numbers. 
Since we know what the structure of a 
BASIC line is as it is stored in memory 
(see ASPD, Vol. 1, No. 1, p. 2) we can 
go into the monitor mode and change 
the line number bytes manually so that 
they contain any line numbers that we 
wish. 

To simplify and automate the process, 
all you have to do is enter this short pro- 
gram and it will do the job in a fraction 
of a second. 


Make it hard to modify 


While my primary use for this pro- 
gram is to produce undeletable credit 
lines for Applesoft programs that I 
write, it is also possible to use this pro- 
gram to make it difficult for someone 
else to modify your programs. If you 
give all your lines in a program the same 
high number, it will be hard to change 
any line in the program. A word of cau- 
tion is needed here however.'If entire 
programs are going to have identical line 
numbers in them, then you won't be able 
to use GOTOs, GOSUBs and THENs 
followed by a line number, because 
there will be no way of telling the com- 
puter to go to a specific line. 


How it works 


Operation of the program is fairly 
straight-forward. After clearing the 
screen and printing out the title page 
(lines 1220-1250) the program gets the 
start of program pointer (lines 
1260-1270) so it knows where to begin 
and then falls into a routine to check if 
the end of the program has been reached 
yet (lines 1280-1320). The check is made 
by comparing the current location in 
memory, which is stored in the accumu- 
lator and the Y-register with the end of 
program pointer located on Zero page 
at AF and BO. 

If the end of the Applesoft program 
has not been reached, the machine- 
language program branches to line 1440 
where the current memory pointers are 
saved. In lines 1460 and 1470 the X and 
Y registers, which are used as offset 
counters, are setup so that they can be 
used to retrieve the two bytes of the new 
line number and store it in place of the 
old line number. This actual replace- 


0367- CA D5 
O36A- C5 D3 
O36D- C8 AE 
0370- C7 C9 
0373- C4 C5 
0376- 8D 

0377- C3 CF 
O37A- D9 D2 
037D- C7 C8 
O380- AO A8& 
0383- AQ AO 
0386- BS B8 
0389- 8D 

O38A- C1 CC 
O38D- AO D2 
0390- C7 C8 
0393- D3 AO 
O396- C5 D3 
0399- D2 D& 
O39C- C4 

O39D- 8D 8D 
O3A0- 8D 00 


1830 


1840 
1850 * 


1860 * Number to which all 


1870 * 
O3A2- FF FF 


-AS -"by Jules H. Gilder” 
«HS 8D 


-AS -"COPYRIGHT (C) 1986" 
«HS 8D 


-AS -"ALL RIGHTS RESERVED* 


.HS 8D8D8D8D00 


lines are changed. 


1880 LINNBR .HS FFFF 


REM BASIC PROGRAM TO INSTALL ALL LINES TO 65535 


REM 
TEXT : HOME 
PRINT : PRINT : 


PRINT : 


PRINT 


PRINT “INSTALLING ‘ALL LINES TO 65535’..." 


FOR X = 768 TO 931 
READ Y 
POKE X,Y 
NEXT X 
PRINT : 
PRINT 


PRINT : 
: PRINT “TYPE 


PRINT : PRINT 


‘CALL 768° 


“INSTALLATION COMPLETE." 
TO RUN PROGRAM." 


DATA 32,88,252,169,73,160,3,32 
DATA 56,3,165,103,164,104,197,175 


DATA 


144,5,196,176,144,1,96,133 


DATA 8,132,9,162,0,160,2,189 


DATA 


162,3,145,8,232, 200, 189, 162 


DATA 3,145,8,160,0,177,8,72 

DATA 200,177,8,168,104,76,14,3 

DATA 133,6,132,7,160,0,177,6 

DATA 240,6,32,237,253,200, 208,246 
DATA 96,193,204,204, 160,204,201, 206 


DATA 


197, 160,206,213,205,194,197,210 


DATA 211,160,212,207,160,182,181,181 


DATA 


179,181,141,141,194,217, 160,202 


DATA 213,204,197,211,160,200,174,160 


DATA 


199,201,204,196,197,210,141,195 


DATA 207,208,217,210,201,199,200,212 


DATA 
DATA 


160, 168,195,169, 160,177, 185,184 
182,141,193,204,204, 160,210,201 


199,200,212,211,160,210,197,211 
197,210,214, 197,196,141,141,141 


141,0,255,255 


ment in done in lines 1480 to 1530 and 
the pointer that tells the program where 
the next line to be worked on is located 
is updated in lines 1540 to 1600. Lines 
1650 to 1730 comprise the routine that 
is used to print text out to the screen and 
lines 1770 to 1840 contain the text itself. 
Finally, line 1880 contains the line num- 
ber that is going to be used to replace 
all of the existing ones. It is stored low 
byte first and in this case is $FFFF, 
which represents the number 65535. 


To make entering the program easy, 
I have included a short Applesoft BAS- 
IC program that will automatically load 
the machine language program for you. 
After the program is entered, you can 
execute it by typing CALL 768. If you 
do that while the BASIC loading pro- 
gram is in memory, all its line numbers 
will be changed to 65535. If you then try 
re-running the program, you see that it 
executes without a problem because it 
contains no GOTOs or GOSUBs. 
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MOVING THE CATALOG TO ANOTHER TRACK 


One very effective way to protect pro- 
grams from being copied is to change 
the track that the catalog is stored on. 
Normally it’s stored on track 17 ($11) 
from sectors 15 ($F) to 1. While chang- 
ing the catalog track will stop the stan- 
dard copy programs (COPYA, FID, 
MUFFIN) it, of course, will not stop the 
bit copier programs from duplicating a 
diskette that uses this technique. 
However, if you combine this technique 
with some of the other copy protection 
schemes we’ve discussed so far, or if you 
move the catalog to track 37 or higher, 
even the popular nibble copier programs 
won't be able to duplicate your diskette. 

While most of track 17 is devoted to 
the catalog, sector 0 of this track has a 
special job. It contains what is known 
as the VTOC (for Volume Table Of 
Contents) and it keeps track of which 
sectors have been used and which are 
available for future storage. In addition 
to keeping track of which sectors are 
available, the presence of this special 
sector makes it possible for you to lock 
out any track and/or sector on the dis- 
kette and make sure that it won’t be 
written to. This is helpful if you want 
to “bury” a serial number on the diskette 
somewhere. We'll get back to a more 
detailed discussion of the VTOC later. 


Moving the VTOC 


There are several different approaches 
that can be used to move the contents 
of track 17. You can choose to move 
just the VTOC, just the catalog data or 
both. If you move just the VTOC, you'll 
still be able to run programs under nor- 
mal DOS, you just won’t be able to save 
anything out to the diskette without the 
risk of damaging it. Nevertheless let’s 
start by moving the VTOC. Moving the 
VTOC is perhaps a misconception be- 
cause we're not going to take an initial- 
ized diskette and then move it’s VTOC, 
although it is possible. Instead, we’re go- 
ing to modify DOS and then use this 
modified DOS to initialize a new dis- 
kette. The modification that we make to 
DOS will cause the new diskette to be 
initialized with the VTOC on another 
track. The modification that we have to 
make to DOS to move the VTOC is a 
simple one and consists of changing only 
a single byte of memory. That byte is lo- 
cated at 44033 ($AC01), and it is the lo- 
cation that contains the number of the 
track on which the VTOC is located. 


This location is used both by the rou- 
tine that initializes a diskette and by the 
routines that load or save programs to 
a diskette. Under normal circumstances 
the number stored in 44033 is 17 ($11). 

We can change the VTOC track by 
simply POKEing a new number into lo- 
cation 44033. For example, from BAS- 
IC we can type in the following line in 
the immediate mode (no line number) 
and cause the VTOC to be saved out to 
track 37 where it cannot be copied by 
standard copy programs. 


POKE 44033,37 


As you will recall, we discussed how to 
add up to 5 tracks to your diskettes in 
the first issue of ASPD (Vol. 1, No. 1, 
p. 8). Since none of the commercial bit 
copier programs copies more than 36 
tracks, storing) the VTOC and catalog 
onto one of these extra tracks is an ef- 
fective copy protection scheme. 


You can move the catalog too 


To make your files inaccessible to 
normal DOS, you can move the catalog 
sectors to track 37 as well. This would 
‘make it almost impossible to access the 
programs on a copied version of the dis- 
kette, especially if the space on track 17 
is released and used to store programs 
on. To change the number of the track 
that DOS goes to, to look for the cata- 
log information, it is only necessary to 
change two locations in DOS. They are 
46012 ($B3BC) and 44764 ($AEDC). 
The first location is used to tell DOS 
which track to write the directory onto, 
and the second location tells DOS which 
track to format as a directory track. 
Both of these locations must contain the 
same track number, which is normally 
17. Once again, by changing the num- 
ber in these two locations, you can 
produce a diskette that has its catalog 
information on track 37, which cannot 
be copied by most copy programs that 
are available. The following BASIC line 
executed in the immediate mode will 
make the changes for you: 


POKE 46012,37 : POKE 44764,37 


There is a big advantage to doing this. 
By putting the catalog and VTOC ona 
track that cannot be copied, you can tell 
users of your protected diskette that they 
can make backup copies of the diskette 
with COPYA, which will not run, and 


save them in case the original becomes 
damaged. Since odds are small that the 
damage will occur on the 37th track, 
most of the time, users will be able to 
restore their damaged original by 
recopying their backup copy onto the 
original. Of course, if the damage does 
occur on the 37th track, the diskette will 
have to be replaced. 


Tell the VTOC about the changes 


Once you’ve modified DOS so that it 
will produce a 37-track diskette and 
moved your VTOC and catalog onto it, 
you must also tell the VTOC that track 
37 is used and that track 17 is available. 
You do this by changing two locations 
in DOS which contain information that 
tells DOS where the catalog track is lo- 
cated. These locations are 44741 
($AECS5) and 44745 ($AEC9). The first 
location (44741) contains the number of 
the track on which the directory is lo- 
cated, multiplied by four, while the se- 
cond location (44745) contains four 
times the directory track number plus 
four. Thus, for standard DOS, 44741 
contains 68 ($44) while 44745 contains 
72 ($48). Interestingly enough, if we use 
68 as an offset into track 17, sector 0 
(the VTOC sector) we get exactly to the 
point where we have four bytes that are 
used to mark the availability of track 17. 
This is not just a coincidence, because 
these two locations are used by DOS to 
create the VTOC bit map. 

Thus, after we make the necessary 
changes to move our directory (or cata- 
log) onto track 37, we have to make 
these changes too. They can easily be 
implemented by typing in the following 


line in the immediate mode: 


POKE 44741,68 : POKE 44745,72 


Now you have completed the modifica- 
tions necessary to move the VTOC and 
the catalog to a different track. All that’s 
left for you to do is initialize your new 
diskette. Don’t forget, if you’re using 
more than 35 tracks on your diskette, 
you'll have to modify DOS as described 
in ASPD Vol. 1, No. 1. While I’ve con- 
centrated on showing you how to move 
the catalog and VTOC to an extra, non- 
standard track, there is obviously no 
reason why it cannot be moved to any 
other track on the diskette. The reason 
I’ve concentrated on these extra tracks 
is, as I mentioned earlier, they cannot 
be easily copied with the current crop of 
copy programs. 

To make the whole task of producing 
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custom diskettes easier, I have included 
a short BASIC program that will take 
care of all the nitty gritty details for you. 
All you have to do is answer the ques- 
tions it asks about the number of tracks 
you want on the diskette and where you 
want the catalog track located. The pro- 
gram does the rest. 


A challenge and a gift 


For those of you who have the time 
and the inclination, here’s a small 
challenge for you. Use the information 
I have just presented to you to come up 
with a program that will produce a dis- 
kette that has two catalog tracks on it. 
You should provide a means of switch- 
ing back and forth between the standard 
catalog and the hidden one so that pro- 
grams can be saved on one or the other. 
Provision should also be made to update 
both VTOCs whenever either one is 
modified so that nothing will be acciden- 
tally overwritten. 

The simplest way to update the 


VTOCs is to first make sure that the 
track with the hidden catalog on it is 
locked out as an in-use track on that 
normal VTOC. You can do this by stor- 
ing zeroes in the appropriate bit map lo- 
cations on track 17, sector 0 (remember 
the offset to the starting location of the 
bit map can be calculated by multiply- 
ing the track number by four. Thus the 
bit map for track 37 would start at byte 
148 ($94) in the VTOC sector. To lock 
out an entire track, four successive bytes 
must be set to zero. After the standard 
VTOC has been modified to protect the 
hidden VTOC, just read the standard 
VTOC sector into memory, modify byte 
number | (the second byte in the sector) 
so that it is equal to the track that the 
hidden catalog is stored on and write it 
out again to the VTOC sector of the hid- 
den catalog track. Now, if you always 
copy the the VTOC sector of the cata- 
log that has just been modified (the cur- 
rently active one) to the VTOC sector 
that was not modified (the inactive one), 
remembering to adjust that second byte 


to the correct track number, you’ll ‘6 
ways have both VTOCs properly updat- 
ed and not have to worry about 
accidentally overwriting something on 
your diskette. 

For your efforts in developing this 
program, the winner will get fame and 
recognition by having it published in 
ASPD, the satisfaction of having deve- 
loped your own protection scheme and 
a free 6-month extension to your sub- 
scription. The second best entry will get 
a free 3-month extension. You may use 
any programs that have already ap- 
peared in ASPD as a starting point if 
you think they’ll be helpful, so let’s see 
you get those entries in. 

If you need more information on just 
how the catalog track is formatted you 
can look in Apple’s DOS manual or in 
one of the handiest books I’ve found on 
the subject, Beneath Apple DOS. If you 
have difficulty find this book, which is 
published by Quality Software, you can 
order it through us at a 10% discount, 
for only $17.95. 


REVIEW: The quikLoader ROM Card 


One of the most useful accessories 
that you can purchase to help you crack 
programs is the quikLoader ROM Card 
from the Southern California Research 
Group (SCRG). Designed to be used in 
an Apple ][, Apple ][ Plus or Apple //e, 
the quikLoader card can hold up to 256 
programs in ROM with a total memory 
capacity of almost half a megabyte. Pro- 
grams can be written in machine lan- 
guage or either Integer or Applesoft 
BASIC. 

The main reason the quikLoader card 
is such a helpful tool in cracking pro- 
grams is that it can be used to interrupt 
a running program and let’s you select 
from a menu, any other program you’d 
like to have run. When the card is ena- 
bled, one of the eight possible ROM 
chips that are installed on it, is selected 
for response to addresses in the $C100 
to $FFFF memory range. At the same 
time, motherboard response in this 
range is inhibited. This is great for the 
cracker because he can now reset direct- 
ly into the monitor or run any other pro- 
gram without having to worry about 
overcoming protection schemes in pro- 
grams that make it impossible to break 
out of the program by pressing RESET. 
When you have a quikLoader in your 
computer, anytime the RESET or 


Control-RESET key is pressed, the card 
is enabled and ROM chip 0 is selected. 
The result is that when RESET is 
pressed, a program in chip 0 is run. This 
program is called QLOS (for quikLoad- 
er Operating System). 

The action that QLOS takes when a 
reset is encountered depends on which 
key was pressed just before. or, at the 
same time as the RESET key and the 
status of the power-up byte at $3F4. By 
pressing the appropriate key concurrent- 
ly with Control-RESET, you can choose 
from a variety of resets. Included in this 
list are a normal reset, forced power-up 
reset, forced disk boot, a catalog of the 
quikLoader ROM(s), execution of 
specific programs from the ROM(s). Be- 
low is a list of the actions allowed when 
a reset is encountered, and the keys that 
must be pressed to implement them. 


Z - Move Integer BASIC, the monitor 
ROM and DOS into RAM, initialize 
DOS and and enter Applesoft BASIC. 
n - (number 0-7) Run a program on chip 
n. 
Q - quikLoader catalog (referred to as 
katalog to differentiate from a disk 
catalog). 

H - Do a Z-Reset and then run the HEL- 
LO program. 


B - Boot DOS by moving DOS to RAM, 
initializing it and entering Applesoft. 
D - Disk boot. 

C - Catalog a diskette. 

M - Enter the monitor mode. 

S - Soft reset (slot 0, 16K RAM card 
reset). 

X - Go to the mini assembler. 


In addition to these reset options, 
there is an additional one call A-reset. 
This is encountered when an undefined 
key is pressed. In an A-reset, the com- 
puter jumps to the address contained in 
$FFFC and $FFFD on the motherboard 
(the main Apple circuit board) if the 
power-up byte is good. If the power-up 
byte is not good, the computer jumps to 
the power-up routine on chip six of the 
quikLoader. 

If you replace the power-up routine 
that is stored in the chip 0 ROM with 
one of your own programs, you can 
have the quikLoader card do anything 
you want when the RESET (or Control- 
RESET) key is pressed. 


Uses very little RAM 


The design philosophy behind the 
quikLoader is to transfer programs that 
are stored on EPROMs into RAM for 
execution. However, programs can be 
run while they reside in the ROM card 
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Oren. how QLOS is run). When this is 


done, very little user RAM is needed. 
The memory that it does need is primar- 
ily used for pointers, counters and tem- 
porary storage. Zero page locations are 
used for most temporary storage and 
certain routines that must run in RAM 
are loaded either into the input buffer 
at $200 or the bottom of the 6502 stack 
at $100. These locations were chosen by 
the board’s-designer Jim Sather (author 
of Understanding Your Apple) so as to 
minimize any likely interference with 


.user programs. And his goal was 


achieved. 

Using the board’s B-RESET feature, 
you can load DOS into the Apple and 
very few memory locations will be 
changed. There’s no multi-stage boot 


‘process involved that wipes out large 


chunks of memory. DOS is loaded 
directly from the card into the final lo- 
cation in memory where it will be run. 
Thus, it is a simple matter to boot up 
a protected diskette, load the program 
into memory, boot normal DOS from 
the quikLoader card, and then save the 
program out to an unprotected diskette. 


eo comes with software 


The quikLoader card has eight sock- 
ets on it for EPROMs. When you buy 
the card, you'll get it with some 
EPROMs already in it. These will con- 
tain DOS 3.3, Integer BASIC, FID and 
COPYA. These programs are licensed 


COPYP Files continued from page 6 


The checking routine is bypassed by 
adding line 485, which is listed below 
and setting the old value of the byte to 
0.5. Actually, any value between 0 and 
1 will do, but 0.5 is easy to remember. 
Thus the parameter file for Financial 
Cookbook becomes: 


485 IF OV > 0 AND OV < | THEN 
500 
1000 DATA 1,6,8,0.5,98 


COPYP will now make a backup copy 
of the program and, without checking 
to make sure this is the correct version 
of the program, modify the diskette so 
that it will work. 


Hayes Terminal Program 


Like the previous program, this one 
was submitted without the value of the 


from Apple Computer. SCRG also has 
other programs available in ROM for 
use with this board. These include the 
Beagle Bros. Double-Take utility and 


Central Point’s Copy J[ Plus. And, if, 
you send them your configured version ° 


of AppleWorks on a diskette, they’ll 
burn it into ROM for you so that you 
can be up and running with it in less 
than 2 seconds. 

The board is extremely versatile and 
can accomodate any combination of 
EPROMSs from the 2K 2716s to the 64K 
27512s. If completely populated with 
64K EPROMs, the quikLoader can 
store almost a half megabyte of 
data.Since the card can be plugged into 
any slot except slot 0 (but including slot 
3 in the Apple //e) it is possible to store 
over 3 MB of data in EPROMs and have 
any of it instantly available. 


Support is superb 


For those of you who may not have 
heard of SCRG, it’s a small company 
that sells a number of hardware acces- 
sories for the Apple. But don’t hold its 
size against it, because you'll be hard 
pressed to find another company, even 
a Fortune 500 one, that supports its 
products as well as SCRG does. While 
my quikLoader card has always worked 
well and I’ve never encountered any 
problems, the company sent around a 
notice that a change had been made to 
the card and the ROMs to enable it to 


byte that is to be changed, Since we do 
not have a copy of this program, we 
can’t check it and find the value of the 
original byte. 


485 IF OV > 0 AND OV < 1 THEN 
500 
1000 DATA 16,3,157,0.5,37. 


Microwave 


Although this program is a few years 
old, it has proven to be a very popular 
one and for that reason, cracking infor- 
mation is included here. 


485 IF OV > 0 AND OV < 1 THEN 
500 . 

1000 DATA 2,1,218,0.5,173 

1010 DATA 2,1,219,0,5,3 

1020 DATA 2,1,220,0.5,129 

1030 DATA 2,1,221,0.5,96 


work with the 27512 EPROMs (I bought 
mine before these chips were available). 
And though SCRG was not obligated 
to, it offered to update my card for free 
if I sent it back to them. I did, and they 
turned it around very quickly. In the 
years that I have owned this card, I have 
had several ocassions to call the compa- 
ny and ask technical questions about 
how or why something was done, or if 
the card could be used for specific ap- 
plications. I always found someone 
technically knowledgeable to talk to, 
usually Phil Wershba himeself (he’s the 
president). In those rare circumstances 
when he couldn’t answer my questions, 
the designer, Jim Sather could. 
SCRG offers a 6 month warranty on 
everything it sells, but I have found that 
if you encounter a problem even after 
the warranty expires, that the company 
will take care of it for you anyway (if 
possible), at no charge. Another nice 
practice of this company is its 10-day 
free trial period. You can order any of 
their products and try them for 10 days. 
If for some reason you’re not happy 
with a product, all you have to do is 
return it for a prompt refund. If you’re 
going to be doing a lot of program 
cracking, or if you just want the added 
convenience of having your most fre- 
quently used programs in ROM ready 
for instant access, then this card is a 
must for you. Price: $179. Source: 
Southern California Research Group, 
P.O. Box 593, Moorpark, CA 93020. 


That’s all it takes to unprotect 
Microwave. 


Give us a hand 


In order for this publication to be 
really useful to you, you have to get in- 
volved. Tell us what you’d like to see 
and also contribute your favorite cracks 
to us. If you took the time out to un- 
protect a program, chances are that 
‘someone else is interested in it too. 
Remember, you get a one-month sub- 
scription extension for every program 
crack you submit and we use. So let’s see 
those helpful hints. 
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6onlaine all of the programs trom the cur- 
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